<?php
$msgValue[0][1]='Waiting for submission.';
$msgValue[0][2]='Acquisition was created in Admin Catalog, but the curator/cataloger needs to run the records through NZME to create the appropriate  .xml file to move along with the records in the Bagit data folder and the Bagit manifest file to the manifest server.  The UI should return Waiting for submission. The next value should be 9';
$msgValue[1][1]='Accepted. BizTalk creating superpackage.';
$msgValue[1][2]='Curator/cataloger has clicked the Accept button on the item review page (itemSummary.php).  The superpackage is being created and moved to the appropriate directory for exposure to LOCKSS. The records are removed from the manifest server as well as the Bagit manifest and NZME .xml file. UI should return Accepted. BizTalk creating superpackage. The next value should be 4.';
$msgValue[2][1]='Rejected. BizTalk removing records.';
$msgValue[2][2]='Curator/cataloged has clicked the Reject button on the item review page (itemSummary.php).  Items are being removed from the Item table, but on the manifest server, the records in the data folder, the Bagit manifest and the NZME .xml file are untouched. UI should return Rejected. BizTalk removing records. The next value should be 3.';
$msgValue[3][1]='Rejected at least once. Waiting for resubmission.';
$msgValue[3][2]='Acquisition was rejected at least one time. Whether data needs to be wrangled or BizTalk mapping and orchestrations need to be modified is to be determined by the curator/cataloger and the pedtech. If only the code is modified,  the original records, manifest file, and NZME .xml file are still on the manifest server waiting to be resubmitted. If data wrangling is needed, these may need to be removed and replaced with new data, manifest file, and NZME .xml file tied to the same acquisition ID values. UI should return Rejected at least once. Waiting for resubmission.  The next value should be 9 when resubmission occurs. (NOTE: If it is decided that the acquisition needs to be removed, the tech will have to remove values from the acquisition table manually. There is no tool to remove an unused acquisition from within the UI.)';
$msgValue[4][1]='Superpackage has been created.';
$msgValue[4][2]='The superpackage has been created and exposed to LOCKSS.  The records are no longer in data folder.  Only item metadata can be viewed on the item pages. UI should return Superpackage has been created. This is the last value for a successful acquisition.';
$msgValue[5][1]='Ready for review.';
$msgValue[5][2]='The records have been processed by BizTalk and a temporary superpackage has been created, the records are still in the data, and the item table has been populated. The items can be reviewed, and the curator/cataloger makes the choice to accept or reject the acquisition based on this review. UI should return Ready for review. The next value should be 1 or 2, depending on acceptance.';
$msgValue[6][1]='Not a valid value';
$msgValue[6][2]='';
$msgValue[7][1]='Not a valid value';
$msgValue[7][2]='';
$msgValue[8][1]='Not a valid value';
$msgValue[8][2]='';
$msgValue[9][1]='BizTalk processing submitted records.';
$msgValue[9][2]='The appropriate manifest and NZME files have been copied into the receive locations on the manifest server, and the BizTalk process has begun.  The Item table is being populated and the physical records remain in the data folder.  As each record is processed it can be reviewed, and a list of the processed records is available. However, the curator/cataloger is not able to accept or reject the acquisition until the process is finished, which may take some time depending on the size and number of records. UI should return BizTalk processing submitted records. The next value should be 5.';
?>